Wireless networks generally comprise a large number of geographically dispersed base stations that provide wireless communications in a designated coverage area served by a wireless service provider. Groups of base stations are connected by land lines to a common mobile switching center (MSC) that provides high-level control over the group of base stations and connects the base stations to the public switched telephone network (PSTN). Each base station (BS) covers a particular geographic area (or cell) and may be comprised of a base transceiver station and a base station controller (BSC).
Base station controllers and base transceiver stations are well known to those skilled in the art. A base station controller is a device that manages wireless communications resources, including the base transceiver station, for specified cells within a wireless communications network. A base transceiver station comprises the RF transceivers, antennas, and other electrical equipment located in each cell site. This equipment may include air conditioning units, heating units, electrical supplies, telephone line interfaces, such as T1/E1 interfaces, and RF transmitters and RF receivers.
Conventional base transceiver stations contain a number of channel cards, wherein each channel card is capable of servicing a call by processing voice and/or data signals transmitted to a mobile station in a forward channel and by processing voice and/or data signals received from the mobile station in a reverse channel. The channel cards are in turn controlled by one or more digital call control processors. In a typical architecture, a base station may contain a primary call control processor and a secondary (or standby) call control processor that operates in the event of a failure of the primary call control processor.
The call control processor executes an application program that performs the basic functions of the base transceiver station, such as call processing, communications protocols, fault management, and the like. Under the control of the application program, the call control processor effectively becomes a plurality of state machines. A state machine is a basic building block of software systems that follow protocols such as call processing, communications protocols, fault management, and other management operations. A state machine as used in this context is described in terms of the following:                State: A place of rest or no change in the state machine.        Event: A stimulus that could cause the state machine to operate and possibly to change to a new state.        Action: An activity performed by the state machine in response to an event.        
Many call control processors are table-driven finite state machines. That is, a message or signal is received by a software task and is converted into an “event”. The event is actually a look-up value into a table that contains the current state. At the entry point identified by the event is a list of actions that need to be run for the given event and for the given state. After all of the actions have been executed, a state transition can occur.
In many systems, state machines interact with one another by passing messages through the operating system. The state machines perform tasks and interact using two queues. One queue is an internal queue, or state machine queue where events are accumulated and the state machine operates on the events in the internal queue. The other queue is the operating system (O/S) message queue. When a task that owns a state machine needs to pass a message to another task, the task uses the O/S message queue to pass the message.
A task pends on the queue until a message arrives. The O/S then schedules the task to run according to some priority scheme or algorithm that the O/S manages. When the task runs, the message is read and a conversion to an event is done. The event is then placed into the internal queue. The internal queue is not an O/S queue because of the overhead in using O/S queues. Events in the internal queue are then used to “walk” (or operate) the state machine until the internal queue is empty. An action caused by an event can generate other events, which get placed into the internal queue.
Speed problems can occur in a call processing system that implements state machines as described above. The most convenient way for state machines to pass events to one another is to pass messages through the O/S. Unfortunately, this requires the O/S to run its scheduling algorithm every time a message is sent. Since some events must be sent to many other tasks, the call processing system is slowed down as the O/S repetitively runs its scheduling algorithm.
There is therefore a need in the art for improved state-machine-based call processing systems. In particular, there is a need for state machines that are capable of interacting with one another with a minimum amount of operating system overhead. More particularly, there is a need for an improved call processing system that uses state machines that can share events without exchanging messages via the operating system.